[小ネタ]AWS Certificate Managerで既存のSSL証明書にサブジェクト代替名(SAN)を追加したかった話

皆さんは「リモート飲み会」、やっていますか？

▲ みんなよくやっていますよね、リモ飲み

こんにちは、AWS事業本部のShirotaです。
私はほとんどリモート飲み会には参加していません。
何故なら、バ美肉をするとPCが激しい唸り声をあげるからです。
このご時世なだけあって家でやる趣味が無限に沸いてきた挙句、どの趣味もそれなりにPCのリソースを食う為騒がしい日々を過ごしております。
さて、今日はAWS Certificate Manager(ACM)を触っていて気になった事があったので調べてみた事を小ネタとしてまとめてみました。

既存のACMの設定にオブジェクト代替名(SAN)は追加できない

いきなり出落ちのような見出しです。実際どういう事なのか見てみましょう。

▲ 本名的な事情で伏せてお送りします

例えば、ACMを用いて以下2つのドメインに関するパブリック証明書を取得している状態だとします。

• shirota.info
• dev.shirota.info(SAN)

そして、以下のような環境で「dev.shirota.info」を用いていたとしましょう。

▲ ちゃんとHTTPS通信したいもんね

ある時、私はこう考えました。
「もう一つ開発環境を増やすから、新しく dev2.shirota.info の証明書を取得しよう。今までと同じようにDNS検証で取得して……後は、他のドメインもいっぱいある環境だし 管理が楽になるように同じZone Apexのドメインの設定は一つにまとめたい から既存のSSL証明書にSANを追加したいな」

▲ Route53にレコードを追加して、ALBのListenerに設定を追加すればいけるな

まずは、ACMに今回新しく追加したいドメインを追加しに行きましょう。

▲ おや……？

パブリック証明書だからという訳でも無く、そもそも選択肢を見る限りドメインの追加ができない事が分かると思います。

追加ができないので対処法を考えてみる

別に証明書をまとめる必要が無い場合でしたら、以下の作業をしてドメインを追加すると楽に作業が済むと思います。

• 追加したいドメインの証明書を新規に発行する
• ALBのListenerにServer Name Indication(SNI)として追加する
• Route53で名前変換ができるようにレコードを追加する

SNIを利用したALBへSSL証明書を設定する方法については、以下ブログが分かり易くまとまっておりますので参考にどうぞ。

ALBで複数のSSL/TLS証明書を設定できるSNIに対応しました | Developers.IO

それでも既存のSSL証明書の設定にドメインを追加したい場合は、以下のように作業をすれば実現する事ができます。

• 追加するドメインを含めた証明書を新規に発行する
• ALBのListenerにSNIとして追加する
• Route53で名前変換ができるようにレコードを追加する
• (必要があれば)デフォルト証明書として入れ替え、今まで使っていた証明書は削除する

それでもドメイン設定をまとめてみたかったのでやってみた

実際にやっていきましょう。

追加するドメインを含めた証明書を発行する

▲ dev2.shirota.infoを追加してみた

既存のドメイン(shirota.infoとdev.shirota.info)に加え、SANとしてdev2.shirota.infoを新規に追加して登録します。

今回はDNS検証で実施した為、証明書を発行して少しすると以下のような状態になりました。

▲ あれ、既存のドメインは検証が済んでいる

そう、DNS検証において 既存のドメインは同じCNAMEが使用されます 。その為、今回は新規に追加したdev2.shirota.infoのCNAMEをRoute53に登録するだけで検証は完了します。

ALBのListenerにServer Name Indication(SNI)として追加する

次に、ALBのListenerにServer Name Indication(SNI)として追加します。
こちらは、前述したブログを参考にして頂ければ簡単にできる作業なので今回はサクッと進めさせてもらいます。

▲ ポチッとな

Route53にレコードを追加する

最後に、Route53に今回追加したドメインのレコードを登録しましょう。

▲ これでおしまい

実際に、登録したドメインにアクセスして、作成したての証明書が利用できている事を確認します。

▲ 取り立てほやほやです

やってみて分かった事や浮かんだ疑問をまとめてみた

SNIの有り難みが分かった

新規で追加のドメインを含めた証明書を発行した場合、既存の証明書との兼ね合いで同じドメインの証明書が重複してしまう為、管理が複雑化する事を避けるとしたら既存の証明書を削除する必要が生じます。
一応、ELBは証明書の入れ替えによってダウンタイムは生じない仕組みになっています。(2014年のAWSの資料しか見つからなかったのですが、もしより最新の資料でこの事が明文化されている資料がありましたら教えて頂けますと幸いです！)

AWS Solutions Architect ブログ: ELBのSSL証明書更新の方法

ですが、SNIで新しいドメインの証明書だけを追加する場合は、上記のようにドメインが重複したSSL証明書は発生しません。
作業が少なくて済みます。

証明書をまとめる事のメリットはある？

今回は意地でも証明書をまとめてみた訳ですが、証明書をまとめる事のメリットはあるのかが気になりました。

現状、ACMを使用する際のデフォルトの制限には以下のようなものがあります。(2020年5月30日現在)

項目	デフォルトのクォータ(上限値)
ACM 証明書の数	1,000(新しいAWSアカウントでは、最初はクォータが最大数より低い場合がある)
ACM 証明書別のドメイン名の数	10

例えば、証明書が既に1000近い場合ですと、上限を意識して証明書をまとめる必要が出てきます 。(上限緩和の申請は可能です)
逆に、現在既に10個のドメインが登録されている証明書を利用している場合は証明書をまとめる事ができない為、確実に新規の証明書を発行する必要があります。
最終的に証明書の総数は増えます。(こちらも上限緩和の申請は可能です)

限定的な状況にはなりますが、このような場合には証明書をまとめる事を考えてみる事が有用になるかもしれないなと思いました。

今回は、既存のSSL証明書に対してドメインが追加できない事を知り、そこからできる対応方法について考えてみました。
同じような状況に出くわした方の参考になれば幸いです。